1. Field
The field relates to visual information systems and, more particularly, to a method and apparatus for providing information on a remote viewing session.
2. Description of the Related Art
Telephones enable people to communicate verbally, but do not enable people to exchange visual information with each other. Historically, when visual information such as a PowerPoint (™ Microsoft Corporation) presentation or a document was to be referenced during a telephone call, the visual information would be transmitted, e.g. emailed, before-hand so that the participants could each have the document locally displayed on their computer during the telephone conference.
Remote Viewing Software has now developed which changes this paradigm, by allowing multiple people to remotely see what is being displayed on one person's computer. They way this type of software generally works, is that a person who wishes to allow other people to view what is being displayed on their monitor will launch the Remote Viewing Software on their local machine. This will start a remote viewing session which other Viewers can join. When a Viewer joins the remote viewing session, a window will open on the remote Viewer's monitor which shows the content that is being shown on the Display's monitor. Software that allows remote viewers to see a Display over a computer network will be referred to as “Remote Viewing Software” (RVS).
FIG. 1 illustrates an example of a way in which information being generated and shown on a monitor of one computer may be viewed remotely. As used herein, the term “Display” will refer to the computer that is sharing information with others. The term “Viewer” will refer to the computers that are receiving information remotely. FIG. 1 shows an example remote viewing system in which a remote viewing service 10 interconnects a Display 12 with one or more Viewers 14. The display 12 includes a remote viewing software client 16 to capture, encode, and transmit information 18 being shown on a monitor 20 associated with Display 12. Each of the Viewers 14 includes a remote viewing software client 22 to receive and decode information 18 which is then shown on monitor 24 of the Viewer 14. The remote viewing software client 22 at the Viewers may be the same as the Display client 16 or a more limited version designed to primarily allow data to be displayed and not configured to capture and transmit data.
In the system shown in FIG. 1, the Display 12 sends data to the remote viewing service 10, which relays the data to the Viewers. This allows the Viewers to have a synchronized view of what is shown on the Display's monitor, so that the participants to the remote viewing session can reference a common visual presentation (information 18).
It is possible for the Display to send data to the server faster than the server can send it to the Viewers. This may occur in instances, for example, where one or more of the Viewers is on a relatively low bandwidth network connection. In this situation, at least some of the data sent by the Display will not be able to be sent to the Viewer. Thus, there is no advantage in having the Display send data faster than the fastest Viewer can receive it. Accordingly, a handshake mechanism has been developed in which the Display will provide updates to the Remote Viewing Service upon request.
FIG. 2 shows one way in which data may be transmitted between a Display and Viewer. In the embodiment shown in FIG. 2, when a Viewer is ready for data, it sends an update request to the server (100). The server forwards the update request to the display (102). The display captures changed screen data and compresses the data to create an update (104). The Display then sends update messages to the server (106). The server forward the update messages to the viewer (108). The viewer receives and renders the data on the screen (110). Once the viewer has received and rendered the complete update, it sends another update request to the server (100). This process iterates for each update to allow the Viewer to control the pace of receipt of updates. If there are multiple viewers in a session, the fastest viewer sets pace of updates and the server will locally handle selection and transmission of updates to the slower viewers. After the display has finished sending an update 106, the next update request received by the server from one of the viewers will cause the server to send a new update request (102) to the Display.
This handshake mechanism guarantees that the display never sends updates faster than the fastest viewer can process them. However, the handshake introduces latency into the update process, which degrades performance. As shown in FIG. 2, there is a finite amount of elapsed time from the time when the Viewer is ready for a new update until a new update starts to arrive. The specific amount of time it takes to begin forwarding a new update to the Viewer includes the network latency between the Viewer and server, the network latency between the server and the Display, the time it takes for the Display to create the update, the network latency between the Display and the server, the network latency between the server and Viewer, and the time it takes for the Viewer to render the update.
Thus, where a handshake mechanism of this nature is used, the Viewer that is setting the pace of updates will need to wait a finite amount of time after sending a request to start receiving updated information from the Display. Accordingly, it would be advantageous to improve this process of providing information on a remote viewing session.